Problems with upgrading 7.1.3 -> 7.2

Поиск
Список
Период
Сортировка
От Chris Ruprecht
Тема Problems with upgrading 7.1.3 -> 7.2
Дата
Msg-id p05101202b88b099d7a59@[192.168.0.6]
обсуждение исходный текст
Ответы Re: Problems with upgrading 7.1.3 -> 7.2  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Hi guys,

Problems ...
OS = RedHat Linux 7.2 (kernel 2.4.9-21)
Build options: --prefix=/home/postgres --with-perl --with-tcl --with-python
Postgres Version 7.2 (Final) for loading data, 7.1.3 for dumping data

I have a database with a few smaller tables and one large one (23
Million records). I tried to dump and load, using pg_dump -fc ... but
I never got pg_restore to load the dump file back - I didn't try hard
enough, I know but ...

I then wrote a script which copies all the data into flat files (copy
xxx to '<file>';) and dumped the schema info separate (pg_dump -s).
With an editor, I split the schema file into two, one to define the
tables, one to define the indexes, I don't want to load data with the
indexes active, it'll take for ever.

Dumping the big table was messy, because Postgres always complained
that the file is too large. I'm running this on RedHat 7.2 which can
create files as big as the disk. and yes, I have ulimit set to
unlimited. Eventually I got it done by using "copy phonelog to
stdout;" and redirected the output into the file I wanted. I then
went ahead and split the file into three parts, using "split
-10000000" and now got three ~ 1GB files called xaa xab and xac.

I set up the new environment (7.2), did an initdb, created the users
and empty databases and loaded the first part of the schema info.
Then I proceeded to load the raw data using "copy". All went well!

I then went ahead to create the indexes and this is where the fun begins:
psql:/tmp/phones.schema.2:136: ERROR:  tuplesort: unexpected end of data
CREATE
CREATE
CREATE
psql:/tmp/phones.schema.2:168: pqReadData() -- backend closed the
channel unexpectedly.
         This probably means the backend terminated abnormally
         before or while processing the request.
psql:/tmp/phones.schema.2:168: connection to server was lost

Line 136 reads:
CREATE  INDEX "i_pl_date_line" on "phonelog" using btree ( "entity"
"varchar_ops", "cdate" "date_ops", "frline" "int4_ops" );

Nothing wrong with this, right?

I then went, and said, ok, try again, of course, there are some
errors for indexes which are already there - ignore those:

psql:/tmp/phones.schema.2:128: ERROR:  Cannot create index:
'i_pc_countrycode' already exists
psql:/tmp/phones.schema.2:136: ERROR:  Relation 0 does not exist
psql:/tmp/phones.schema.2:144: ERROR:  Cannot create index:
'i_pl_entity_date' already exists
psql:/tmp/phones.schema.2:152: ERROR:  Cannot create index:
'i_pl_loadtimestamp' already exists
psql:/tmp/phones.schema.2:160: ERROR:  Cannot create index:
'i_pl_prefix' already exists
psql:/tmp/phones.schema.2:168: pqReadData() -- backend closed the
channel unexpectedly.
         This probably means the backend terminated abnormally
         before or while processing the request.
psql:/tmp/phones.schema.2:168: connection to server was lost

At this point, I don't know any further. As this is my production db,
I will revert back to 7.1.3 for the time being. Any input is welcome.

Best regards,
Chris

--
Chris Ruprecht
Network grunt and bit pusher extraordinaíre

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Restore Question
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problems with upgrading 7.1.3 -> 7.2